home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000037_owner-urn-ietf _Fri Jan 31 01:46:12 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25453 for urn-ietf-out; Fri, 31 Jan 1997 01:46:12 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25436 for <urn-ietf@services.bunyip.com>; Fri, 31 Jan 1997 01:45:10 -0500
  3. Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA21457  (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 01:45:08 -0500
  5. Received: from montana (transitory13.lanl.gov [128.165.7.187]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id XAA03311; Thu, 30 Jan 1997 23:44:07 -0700 (MST)
  6. Message-Id: <199701310644.XAA03311@acl.lanl.gov>
  7. From: "Ron Daniel Jr." <rdaniel@lanl.gov>
  8. To: "omar syed" <osyed@lerc.nasa.gov>
  9. Cc: "URL mailing list" <ietf-url@imc.org>, <urn-ietf@bunyip.com>
  10. Subject: Re: [URN] Re: Relative URLs and URNs
  11. Date: Thu, 30 Jan 1997 23:43:33 -0700
  12. X-Msmail-Priority: Normal
  13. X-Priority: 3
  14. X-Mailer: Microsoft Internet Mail 4.70.1155
  15. Mime-Version: 1.0
  16. Content-Type: text/plain; charset=ISO-8859-1
  17. Content-Transfer-Encoding: 7bit
  18. Sender: owner-urn-ietf@services.bunyip.com
  19. Precedence: bulk
  20. Reply-To: "Ron Daniel Jr." <rdaniel@lanl.gov>
  21. Errors-To: owner-urn-ietf@bunyip.com
  22.  
  23. Thus spoke Omar Syed:
  24.  
  25. > The rest of what I say is predicated on the following:
  26. > 
  27. > 1. urn:<NID>:<NSS>
  28. > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
  29. > 3. the details of interpereting a <NSS> are know only to
  30. >    coresponding <NID> resolvers
  31. > 4. clients must use appropriate resolvers to map the <NSS> to 
  32. >    a location or resource
  33.  
  34. I think assumption 2 is in error. Clients that know the structure of
  35. a name in a particular namespace are likely to manipulate it. Further,
  36. the rules in RFC1630 about only using '/' to denote hierarchy and
  37. mandating a particular order for the elements in the hierarchy are
  38. intended (I assume) to provide enough commonality across namespaces
  39. that clients will be able to process identifiers from novel namespaces.
  40.  
  41. > But the client is not allowed to
  42. > interperet the <NSS> so it cannot replace the "Res1"
  43. > from the previous absolute URN with "Res2" to create a new
  44. > URN.
  45.  
  46. Yes, it could do that.
  47.  
  48. > Now for the serious concerns:
  49. > 
  50. > Lets say that another valid reference for resouce r1 is:
  51. >   urn:nid2:X:Y:resource1
  52. > 
  53. > Suppose a client uses this absolute URN to get r1 and then
  54. > comes across the relative URN: "Res2".
  55. > 
  56. > The first concern is that the client won't even know that
  57. > the author of resource r1 had intended the relative URN
  58. > to be retrieved using the "urn:nid1" scheme.  Is there a
  59. > way for an author to specify the intended scheme along
  60. > with the relative URN?
  61.  
  62. This is the sort of problem I am running into now in our tests, where
  63. we have a bunch of HTML pages we are retroactively assigning URNs to.
  64. Since those pages have lots of relative links in them, we can either:
  65.   1) Make sure our new URNs reflect the same filesystem arrangement
  66.      as the pages do.
  67.   2) Modify the pages to make all the references absolute.
  68. Alternative 1 certainly is unattractive, since a major point of URNs is
  69. to provide independence from the filesystem organization du jour.
  70.  
  71. But, to answer your question, there are two appraoches the author of
  72. an HTML page can use to say that the references are relative to BASE-URN-1
  73. instead of BASE-URN-2. One is just to use absolute references. The second
  74. is to use the BASE tag of HTML.
  75.  
  76.  
  77. > Also will authors have to maintain multiple relative URN
  78. > references (for each <NID> that can be used to reference it)?  
  79. > For example:
  80. >   <a href="urn:nid1:/Res2" href="urn:nid2:/resource2">
  81. > Will HTML specs be modified to allow this?
  82.  
  83.  
  84. > Finally, the most serious concern:
  85. > 
  86. > It is quite possible for there to be multiple ways
  87. > to reach a reference even within the same name space.
  88. > For example:
  89. >   urn:nid1:A:B:Res1
  90. > and
  91. >   urn:nid1:A:res1
  92. > may both be valid.  However, the URN:
  93. >   urn:nid1:A:Res2
  94. > may not be defined.  So a client could request the URN:
  95. >   urn:nid1:A:res1/urn:nid1:/Res2
  96. > How would the resolver know to remap 'A:res1' to 'A:B:Res1'
  97. > since the first is already a valid reference in its name space.
  98.  
  99. It wouldn't.
  100.  
  101.  
  102. Ron Daniel Jr.              voice:+1 505 665 0597
  103. Advanced Computing Lab        fax:+1 505 665 4939
  104. MS B287                     email:rdaniel@lanl.gov
  105. Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
  106. Los Alamos, NM, USA, 87545  
  107.  
  108.